MDEV-39880 Reïmplement MDEV-37146 to include MDEV-39519 by ParadoxV5 · Pull Request #5458 · MariaDB/server

ParadoxV5 · 2026-07-27T00:49:01Z

Resolves MDEV-39880

MDEV-39519 added MySQL compatibility to mariadb-dump --dump-slave by attempting SHOW REPLICA STATUS first and then SHOW SLAVE STATUS.
This conflicted with MDEV-37146, where mariadb-dump --dump-slave queries either SELECT … FROM information_schema.SLAVE_STATUS or SHOW ALL SLAVES STATUS depending on the server version.

This commit merges MDEV-37146 and MDEV-39519:

Use MDEV-39519’s strategy based on syntax error handling.
Use MDEV-37146’s preference order:
1. SELECT … FROM information_schema.SLAVE_STATUS
2. SHOW ALL SLAVES STATUS
3. SHOW REPLICA STATUS (for MySQL compatibility only)
- Send STOP/START REPLICA SQL_THREAD FOR CHANNEL '…' commands for both MariaDB (est. 10.7) and MySQL.
Refactor column indices to variables set when a query succeeds.
Partially revert MDEV-37146’s removal of --dump-slave’s support for pre-GTID & pre-multi-source, but tailored for MySQL compatibility; coverage for MariaDB pre-10.0 is not fully restored.
(That would require a 4th command: SHOW SLAVE STATUS.)

Disclaimer re. «Consistent use of terminology "master" and "slave" in replication development»:

All appearances of REPLICA in this PR are about MySQL compatibility and are not directly related to… that movement.

ParadoxV5 · 2026-07-27T00:52:15Z

@@ -6603,16 +6635,18 @@ static int do_show_slave_status(MYSQL *mysql_con,
    if (use_gtid)


For 10.11: Warn when using --gtid to dump MySQL or a pre-GTID MariaDB?

The behaviour before MDEV-37146 or MDEV-39519 appears to still dump no-MariaDB-GTID servers with the following snippet, just not followed by SET GLOBAL gtid_slave_pos='…';.

-- The deferred gtid setting for slave corresponding to the dump-slave CHANGE-MASTER follows -- GTID position to start replication:

ParadoxV5 · 2026-07-27T00:53:01Z

+    have_info_schema_slave_status= false;
+    // Between 10.0 and 11.5 inclusive
+    switch (mysql_query_with_error_report(mysql_con, &slave_status_res,
+      "SHOW ALL SLAVES STATUS", true


I considered using REPLICAS here as well, but I noticed that if MySQL suddenly adds SHOW ALL REPLICAS STATUS, but in MySQL’s column order rather than MariaDB’s, then these assumptions would break in the absence of version checks.

(It’s not MDEV-39880’s concern, but version ≥ 10.0 checks probably will also fall apart soon with the upcoming MySQL 26.7.
They have not released their last quarter’s commits, so the only way to verify is to download their entire pre-release, which I’m not bothering.)

On the other hand, I assume that both MariaDB deleting the SLAVES keyword and MySQL reviving it are very unlikely.

ParadoxV5 · 2026-07-27T00:53:41Z

-  if (mysql_query_with_error_report(mysql_con, &slave_status_res,
-    have_info_schema_slave_status ?
+  // 11.6 and above
+  switch (mysql_query_with_error_report(mysql_con, &slave_status_res,


I’m tempted to revive my old draft implementation based on virtual methods.
But the old argument holds that we will eventually deprecate 11.4 & before.
It’s also really MySQL’s problem that their SQL version of SHOW REPLICA STATUS is still stuck behind Perf. Schema.

I did not extend mysql_query_with_retry() because this code design requires an overly detailed flexibility.
(Although it’d be cleaner with that virtual methods code design.)

Currently, the only other uses of mysql_query_with_retry() are in --master-data ’s and --delete-master-logs’s code, but they both query SHOW MASTER STATUS first and then SHOW BINARY LOG STATUS.

It’s not my current focus to get them to share their results, though (but it’s viable because --delete-master-logs includes --master-data).

Side note

While I removed --dump-slave & --apply-slave-statements support for pre-10.0 in MDEV-37146, I did not touch --master-data.

ParadoxV5 · 2026-07-27T00:58:13Z

This PR does not add --apply-slave-statements support for MySQL.
But I doubt that mariadb-dump should support outputting for MySQL.

STOP/START REPLICA also means STOP/START ALL SLAVES on MySQL, but not on MariaDB, so this is a (if not the only) detail where an output intended for MySQL would have an incomplete effect on MariaDB.

… which reminds me that I must use STOP/START REPLICA SQL_THREAD FOR CHANNEL '…', which is compatible with both MariaDB 10.7 and MySQL.
~~fixing now~~ done

[P.S.] 10.6 isn’t dead dead tho…
[P.P.S] … eh screw it for today; ES and other extended supporters can add their own code branch or backport FOR CHANNEL to their 10.6.

So should the MDEV-39519 base…
But the old code design can only send the base STOP/START REPLICAL SQL_THREAD to MySQL, which works, just inconvenient.
Oh well.

MDEV-39519 added MySQL 8 compatibility to `mariadb-dump --dump-slave` by attempting `SHOW REPLICA STATUS` first and then `SHOW SLAVE STATUS`. This conflicted with MDEV-37146, where `mariadb-dump --dump-slave` queries either `SELECT … FROM information_schema.SLAVE_STATUS` or `SHOW ALL SLAVES STATUS` depending on the server version. This commit merges MDEV-37146 and MDEV-39519: * Use MDEV-39519’s strategy based on syntax error handling. * Use MDEV-37146’s preference order: 1. `SELECT … FROM information_schema.SLAVE_STATUS` 2. `SHOW ALL SLAVES STATUS` 3. `SHOW REPLICA STATUS` (for MySQL compatibility _only_) * Send `STOP`/`START REPLICA SQL_THREAD FOR CHANNEL '…'` commands for both MariaDB (est. 10.7) and MySQL. * Refactor column indices to variables set when a query succeeds. * Partially revert MDEV-37146’s removal of `--dump-slave`’s support for pre-GTID & pre-multi-source, but tailored for MySQL compatibility; coverage for MariaDB pre-10.0 is not fully restored.

bnestere

Hi @ParadoxV5 !

Thanks for working on this. Please see my notes.

bnestere · 2026-07-29T19:28:32Z

-    return(1);
+      " WHERE Slave_SQL_Running <> 'No'", true
+  )) {
+  default:


default should conventionally be last in a switch-case. Though I suppose you did it here to keep case -1 last to make it easier to read this series of switch/if nests. I think that's fine, though any time you break convention, please add a comment to justify why. Don't assume it will be obvious for others :)

bnestere · 2026-07-29T19:31:09Z

-          NAME_CHAR_LEN, row[/* Connection_name */ 0]);
+      char query[39 + NAME_CHAR_LEN]; // sizeof(snprintf)
+        snprintf(query, sizeof(query),
+          "STOP REPLICA SQL_THREAD FOR CHANNEL '%.*s'", // 10.7+ or MySQL


Why use FOR CHANNEL? Won't this break when running on MariaDB 10.6 (still supported)?

bnestere · 2026-07-29T19:40:27Z

  }

-  if (get_gtid_pos(gtid_pos, false))
+  if (have_mariadb_gtid)


Is this a bug fix for MySQL? It looks like, before, against MySQL, we would error and return here. Does the rest of the dump actually work against MySQL? If not, it is probably better to error than to silently output commands which won't actually work.

Alternatively, you mention

For 10.11: Warn when using --gtid to dump MySQL or a pre-GTID MariaDB?

I'd say this is error-worthy rather than warn.

bnestere · 2026-07-29T19:43:10Z

+  ptrdiff_t connection_name, slave_sql_running,
+            master_host, master_port,
+            relay_master_log_file, exec_master_log_pos;
+} slave_status_indices;


Neat pattern here, I like this

bnestere · 2026-07-29T19:51:41Z

      mysql_free_result(slave);
      return 1;
    }
+    slave_status_indices= {0, /* unused */ 3, 1, 2, 3, 4};


Why is slave_sql_running assigned to 3 if it is unused? I'd suggest making it an obviously wrong number (like max ptrdiff_t).

bnestere · 2026-07-29T20:01:09Z

-  if (mysql_query_with_error_report(mysql_con, &slave_status_res,
-    have_info_schema_slave_status ?
+  // 11.6 and above
+  switch (mysql_query_with_error_report(mysql_con, &slave_status_res,


mysql_query_with_error_report returns -1 only on ER_PARSE_ERROR. I don't think it will fire when missing the information_schema.slave_status. You likely have to extend mysql_query_with_error_report() to return -1 also on missing slave_status.

bnestere · 2026-07-29T20:06:06Z

+      char query[39 + NAME_CHAR_LEN]; // sizeof(snprintf)
+        snprintf(query, sizeof(query),
+          "STOP REPLICA SQL_THREAD FOR CHANNEL '%.*s'", // 10.7+ or MySQL
+          NAME_CHAR_LEN, row[slave_status_indices.connection_name]);


slave_status_indices.connection_name isn't initialized here when have_info_schema_slave_status. Though note this isn't true for the parent access to slave_status_indices:

if ((have_info_schema_slave_status || strcmp(row[slave_status_indices.slave_sql_running], "No")))

which first checks have_info_schema_slave_status.

I think the information_schema.slave_status column name strings & its slave_status_indices should be initialized together.

bnestere · 2026-07-29T20:15:50Z

@ParadoxV5 One more thing I forgot to mention in my review - we should have this manually tested across old MariaDB and various MySQL versions. Please coordinate that with @mariadb-SusilBehera.

ParadoxV5 requested a review from bnestere July 27, 2026 00:49

ParadoxV5 added MariaDB Corporation Replication Patches involved in replication labels Jul 27, 2026

This comment was marked as spam.

Sign in to view

ParadoxV5 commented Jul 27, 2026

View reviewed changes

ParadoxV5 force-pushed the MDEV-39880 branch from 389e7f4 to 69bc29c Compare July 27, 2026 01:56

ParadoxV5 force-pushed the MDEV-39880 branch from 69bc29c to e3e8bb0 Compare July 27, 2026 20:51

bnestere requested changes Jul 29, 2026

View reviewed changes

		@@ -6603,16 +6635,18 @@ static int do_show_slave_status(MYSQL *mysql_con,
		if (use_gtid)

Uh oh!

Uh oh!

Conversation

ParadoxV5 commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Disclaimer re. «Consistent use of terminology "master" and "slave" in replication development»:

Uh oh!

This comment was marked as spam.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Side note

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ParadoxV5 Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bnestere left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bnestere commented Jul 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

ParadoxV5 commented Jul 27, 2026 •

edited

Loading

ParadoxV5 Jul 27, 2026 •

edited

Loading